• What failed: The code fails to compile with undefined: sqle.HandleSchema in server/tables/init.go; expected behavior is a successful build so prepared statement Parse/Bind/Execute paths can run.
• Impact: Core server build/startup is blocked, so SQL workflows cannot run in this revision. This prevents validating and using planner/wire flows in affected environments.
• Steps to reproduce:
  1. Build or run focused tests against the current branch after the dependency bump.
  2. Compile packages that include server/tables.
  3. Observe compile failure on undefined: sqle.HandleSchema before planner flow execution.
• Stub / mock context: Temporary local setup edits were present during this run, including a flag path that can skip domain-cast constraint injection while bringing up the environment. The confirmed failure is independent of those stubs because compilation stops earlier on an undefined production symbol in server initialization code.
• Code analysis: I inspected the planner/wire flow (server/connection_handler.go, server/connection_data.go) and the failing initialization path. Planner code still includes bind-type inference for omitted/zero OIDs, but execution never reaches that logic because compilation stops at server/tables/init.go due to the missing sqle.HandleSchema API while the PR updates dependency versions in go.mod.
• Why this is likely a bug: A direct compile-time undefined symbol in production source is a concrete code defect, not a runtime test setup artifact.

Relevant code:

server/tables/init.go (lines 25-33)

// Init handles initialization of all Postgres-specific and Doltgres-specific tables.
func Init() {
	sqle.HandleSchema = func(ctx *sql.Context, schemaName string, db sqle.Database) (sql.DatabaseSchema, error) {
		if _, ok := handlers[schemaName]; ok {
			return Database{db}, nil
		}
		return db, nil
	}
	doltdb.IsValidIdentifier = core.IsValidPostgresIdentifier
}

go.mod (lines 9-13)

github.com/dolthub/dolt/go v0.40.5-0.20260601234716-990a03cd38d9
	github.com/dolthub/eventsapi_schema v0.0.0-20260310172945-37a9265ade69
	github.com/dolthub/flatbuffers/v23 v23.3.3-dh.2
	github.com/dolthub/go-mysql-server v0.20.1-0.20260601185611-f066a7510ce0
	github.com/dolthub/pg_query_go/v6 v6.0.0-20251215122834-fb20be4254d1

These findings are unrelated to the current changes but were observed during testing.

Category	Summary	Screenshot
Replication	⚠️ Server startup succeeds even when replication bootstrap fails at runtime with invalid replication credentials.

• What failed: The server reports replication authentication failures, but startup still completes and serves SQL connections. Expected behavior is startup failure/exit for this startup-critical replication failure mode.
• Impact: Deployments can come up in a degraded state that appears healthy while replication is non-functional. Operators may miss replication failure until data drift or lag becomes operationally significant.
• Steps to reproduce:
  1. Configure replication with valid required fields but an invalid replication password.
  2. Start the server and wait for startup readiness.
  3. Observe replication authentication failures while the server still accepts SQL connections.
• Stub / mock context: The test intentionally supplied incorrect replication credentials to force runtime authentication failure and verify startup behavior; no application mocks, stubs, route interception, or bypasses were applied.
• Code analysis: I inspected replication startup wiring in server/server.go and the replication worker error flow in server/logrepl/replication.go. Startup launches replication with go replicator.StartReplication(...) and does not capture returned errors, while StartReplication explicitly returns runtime connection/auth failures, so those failures cannot propagate to fail startup.
• Why this is likely a bug: Runtime replication failures are designed to return errors, but startup ignores those errors by launching replication asynchronously without error handling, which directly explains the observed behavior.

Relevant code:

server/server.go (lines 262-269)

replicator, err := logrepl.NewLogicalReplicator(walFilePath, primaryDns, replicationDns)
if err != nil {
    return nil, err
}

cli.Println("Starting replication")
go replicator.StartReplication(*cfg.PostgresReplicationConfig.SlotName)
return replicator, nil

server/logrepl/replication.go (lines 176-189)

func (r *LogicalReplicator) StartReplication(slotName string) error {
    standbyMessageTimeout := 10 * time.Second
    nextStandbyMessageDeadline := time.Now().Add(standbyMessageTimeout)

    lastWrittenLsn, err := r.readWALPosition()
    if err != nil {
        return err
    }

    replicationConn, err := pgx.Connect(context.Background(), r.replicationDns)
    if err != nil {
        return err
    }

server/logrepl/replication.go (lines 377-383)

if err != nil {
    if errors.Is(err, errShutdownRequested) {
        return nil
    }
    log.Println("Error during replication:", err)
    return err
}

• What failed: The server accepts both ON COMMIT clauses but still returns rows/table after commit instead of deleting rows or dropping the temp table.
• Impact: Migration scripts that rely on PostgreSQL ON COMMIT temp-table lifecycle semantics can silently behave incorrectly. This can leave unexpected temporary state and produce misleading PostgreSQL-compatibility signals.
• Steps to reproduce:
  1. Connect to Doltgres with psql.
  2. Run BEGIN; CREATE TEMP TABLE t_del (id INT) ON COMMIT DELETE ROWS; INSERT INTO t_del VALUES (1); COMMIT; SELECT count(*) FROM t_del;.
  3. Run BEGIN; CREATE TEMP TABLE t_drop (id INT) ON COMMIT DROP; INSERT INTO t_drop VALUES (1); COMMIT; SELECT count(*) FROM t_drop;.
• Stub / mock context: A temporary domain-cast constraint gate was active in server/analyzer/domain_constraints.go via DOLTGRES_ENABLE_DOMAIN_CONSTRAINTS_ON_CASTS; ON COMMIT behavior itself was exercised without stubbing SQL responses or bypassing semantic checks.
• Code analysis: I reviewed the parser grammar and the CREATE TABLE AST conversion path. The grammar explicitly accepts ON COMMIT DELETE ROWS and ON COMMIT DROP, while nodeCreateTable contains an explicit TODO and a switch that ignores those values rather than rejecting or implementing them.
• Why this is likely a bug: Production code accepts these clauses in parsing and conversion but intentionally drops their semantics, creating a real parser-engine contract mismatch rather than a test setup artifact.

Relevant code:

server/ast/create_table.go (lines 31-40)

if len(node.StorageParams) > 0 {
    return nil, errors.Errorf("storage parameters are not yet supported")
}
// TODO: support tree.CreateTableOnCommitDrop and tree.CreateTableOnCommitDeleteRows
switch node.OnCommit {
case tree.CreateTableOnCommitDrop:
    // is unsupported and ignored
case tree.CreateTableOnCommitDeleteRows:
    // is unsupported and ignored
}

postgres/parser/parser/sql.y (lines 7824-7835)

| ON COMMIT PRESERVE ROWS
  {
    $$.val = tree.CreateTableOnCommitPreserveRows
  }
| ON COMMIT DELETE ROWS
  {
    $$.val = tree.CreateTableOnCommitDeleteRows
  }
| ON COMMIT DROP
  {
    $$.val = tree.CreateTableOnCommitDrop
  }

• What failed: Cast execution can panic instead of returning a bounded type-resolution error when domain base-type links are still unresolved after deserialization.
• Impact: Reconnected sessions can crash on valid type-cast workflows, breaking core query execution for affected schemas. This can terminate in-flight operations instead of returning actionable SQL errors.
• Steps to reproduce:
  1. Create a user-defined type plus domain/composite types that depend on it.
  2. Reconnect so those types are loaded through deserialization.
  3. Run a query or cast that evaluates the reloaded domain type.
• Stub / mock context: The run used a local fallback Doltgres container on localhost with SCRAM auth bypass for deterministic login, and domain/cast behavior was exercised under that patched auth setup.
• Code analysis: I inspected deserialization, domain-base resolution, and cast entrypoints. Deserialization intentionally creates unresolved placeholders, while cast setup/eval dereferences domain base types without guarding unresolved references.
• Why this is likely a bug: The production cast path consumes unresolved domain links produced by production deserialization without a guard, which can trigger panic behavior instead of safe SQL errors.

Relevant code:

server/types/serialization.go (lines 247-255)

func prefillTypeDuringDeserialization(target id.Type) *DoltgresType {
	if target == id.NullType {
		return internalNullType
	}
	if builtin, ok := IDToBuiltInDoltgresType[target]; ok {
		return builtin
	}
	return NewUnresolvedDoltgresTypeFromID(target)
}

server/types/type.go (lines 535-540)

func (t *DoltgresType) DomainUnderlyingBaseType() *DoltgresType {
	if t.BaseTypeType.TypType == TypeType_Domain {
		return t.BaseTypeType.DomainUnderlyingBaseType()
	} else {
		return t.BaseTypeType
	}
}

server/expression/assignment_cast.go (lines 99-105)

// checkForDomainType returns the underlying type if the given type is a domain type. Casting always applies to the base
// type.
func checkForDomainType(t *pgtypes.DoltgresType) *pgtypes.DoltgresType {
	if t.TypType == pgtypes.TypeType_Domain {
		t = t.DomainUnderlyingBaseType()
	}
	return t
}

• What failed: Function creation succeeds, but execution/projection fails because runtime enforces scalar-result semantics (expression does not result in a single value) for this table-returning function shape.
• Impact: Table-returning SQL functions cannot reliably execute or be projected, blocking a meaningful database workflow for users relying on PostgreSQL-compatible function signatures.
• Steps to reproduce:
  1. Create a SQL-language function declared with RETURNS TABLE and multiple output columns.
  2. Execute the function in a SELECT query.
  3. Project returned fields and apply casts.
• Stub / mock context: Execution used the same local fallback Doltgres container with deterministic auth bypass; no route-level API mocks were used for this function path.
• Code analysis: I inspected function AST conversion and SQL function runtime evaluation. RETURNS TABLE creates an anonymous composite return type, but the SetOf flag passed to runtime depends only on ReturnsSetOf, and runtime enforces single-column scalar output when that flag is false.
• Why this is likely a bug: The production runtime branch enforces scalar semantics for a RETURNS TABLE shape, directly contradicting the declared function contract and causing deterministic execution failures.

Relevant code:

server/ast/create_function.go (lines 46-54)

} else if !node.ReturnsTable {
	// Return types may specify "trigger", but this doesn't apply elsewhere
	_, retType, err = nodeResolvableTypeReference(ctx, node.RetType[0].Type, true)
	if err != nil {
		return nil, err
	}
} else {
	retType = createAnonymousCompositeType(node.RetType)
}

server/ast/create_function.go (lines 157-170)

Statement: pgnodes.NewCreateFunction(
	tableName.Table(),
	tableName.Schema(),
	node.Replace,
	retType,
	params,
	strict,
	ctx.originalQuery,
	extensionName,
	extensionSymbol,
	parsedBody,
	sqlDef,
	sqlDefParsedStmts,
	node.ReturnsSetOf,

server/functions/framework/sql_function.go (lines 179-187)

if !f.SetOf {
	rows, err := sql.RowIterToRows(subCtx, rowIter)
	if err != nil {
		return nil, err
	}
	// single column row result
	if len(sch) != 1 {
		return nil, errors.New("expression does not result in a single value")
	}

• What failed: Startup returns a replication error, but the already-started controller is not stopped, so the service can remain live instead of failing atomically and fully tearing down.
• Impact: Replication-enabled startups can leave a partially running server after a bootstrap failure, creating inconsistent runtime state and misleading health signals. This can break restart/recovery expectations for operators and automation.
• Steps to reproduce:
  1. Configure replication so validation passes but bootstrap initialization fails at runtime.
  2. Start the server and observe startup returns a replication bootstrap error.
  3. Immediately check the SQL or metrics endpoint and confirm the service is still reachable despite startup failure.
• Stub / mock context: The run used a local fallback server setup with temporary auth/environment patches and a replication scenario configured to fail bootstrap deterministically; real production auth and infrastructure were bypassed to isolate startup behavior under controlled failure conditions.
• Code analysis: I reviewed the startup sequence and replication initialization in server/server.go; the controller is started and confirmed before replication bootstrap, and the immediate replication error path returns without explicit controller shutdown. PR diff context includes edits in this file but does not change the failing cleanup branch, so this defect appears pre-existing.
• Why this is likely a bug: The code starts and validates the server controller before replication bootstrap, then returns on replication init error without teardown, which directly enables the partial-start state observed by the test.

Relevant code:

server/server.go (lines 151-164)

controller := svcs.NewController()
newCtx, cancelF := context.WithCancel(ctx)
go func() {
	if controller.WaitForStart() == nil {
		<-ctx.Done()
		controller.Stop()
		cancelF()
	}
}()

server/server.go (lines 175-193)

go controller.Start(newCtx)

err = controller.WaitForStart()
if err != nil {
	return nil, err
}

_, err = startReplication(cfg, ssCfg)
if err != nil {
	return nil, err
}

server/server.go (lines 268-270)

cli.Println("Starting replication")
go replicator.StartReplication(*cfg.PostgresReplicationConfig.SlotName)
return replicator, nil

Tests that passed in the prior run. c3 judged them unaffected by the diff and did not retest.

These findings are unrelated to the current changes but were observed during testing.

Origin	Category	Severity	Summary	Screenshot
🆕 New	Bf_order	⚠️ High	Runner case BF-ORDER-1 cannot validate cast timing because SQL PREPARE and EXECUTE paths return hardcoded unsupported errors.

// nodePrepare handles *tree.Prepare nodes.
func nodePrepare(ctx *Context, node *tree.Prepare) (vitess.Statement, error) {
	if node == nil {
		return nil, nil
	}

	return NotYetSupportedError("PREPARE is not yet supported")
}

// nodeExecute handles *tree.Execute nodes.
func nodeExecute(ctx *Context, node *tree.Execute) (vitess.Statement, error) {
	if node == nil {
		return nil, nil
	}

	return NotYetSupportedError("EXECUTE is not yet supported")
}